1. Field of the Invention
This invention is related to the field of restoring computer system data from backup and, more particularly, to providing device drivers for restoring to a system.
2. Description of the Related Art
Unattended, or automated, installs of operating systems may be used in a variety of situations. For example, various backup and restore products are used to safeguard software and data state on a computer system. When a failure occurs on the computer system, the failure may be corrected and the computer system state may be restored. Alternatively, a new computer system may replace the failing computer system, and the state may be restored to the new computer system. In either case, so called “bare metal” backup and restore products may begin the restore process with “bare metal” (that is, no software installed on the computer system yet, including operating system software). It may be desirable to install the operating system in an automated/unattended fashion in such circumstances since the restore may be initiated by an administrator/user who is not physically near the computer system to which the restore is being performed. Additionally, it may be desirable to perform the install in an automated/unattended fashion to simplify the restore process and reduce the opportunity for administrator/user error in the process. Other software products may also use automated operating system installs. For example, provisioning software products outfit a computer system with the software resources and configuration needed to perform one or more tasks. Provisioning software may make use of an automated operating system installation to provision a computer system with the desired operating system.
To properly perform an unattended operating system installation, the device drivers used by at least some of the hardware devices in the computer system on which the installation is to occur (the “target computer system”) are required. Device drivers may be more briefly referred to herein as drivers. In some cases, the operating system installation media may include drivers for the hardware devices, but in other cases the drivers must be provided from another source.
Of particular concern are the drivers for any mass storage device (MSD) controllers in the computer system. The operating system is to be installed on the MSDs in the system, and thus the MSDs need to be accessible during the installation process. Accordingly, drivers for the MSD controllers are needed during the installation process.
For some operating systems, such as the Windows™ operating system family from Microsoft Corporation (Redmond, Wash.), a file is used to identify the drivers for installation during a text-mode portion of the installation, prior to starting the operating system itself. For example, Windows expects a file having the name “txtsetup.oem” to identify such drivers. Drivers may be identified using driver information files (“inf” files in Windows) for the graphical-mode portion of the installation (e.g. after the operating system has been started). Various MSD controller manufacturers identify drivers by listing them in either the txtsetup.oem file, in various inf files, or both. Some MSD controller manufacturers do not include a txtsetup.oem file on their installation media, or include a txtsetup.oem file that lists one or more inf files that include the desired drivers. Additionally, if drivers are gathered from another source than a manufacturer's installation medium, there may be no txtsetup.oem file. In some target computer systems, more than one MSD controller is included and the MSD controllers use different drivers. However, Windows expects a single txtsetup.oem file to identify the drivers for each MSD controller.
The VERITAS Bare Metal Restore™ (BMR) product available from VERITAS Software Corporation (Mountain View, Calif.) is one example of a backup/restore product which uses automated operating system installation. Accordingly, BMR creates a txtsetup.oem file for use in a given installation. If the target computer system has more the one MSD controller, information from more than one source may need to be merged into the txtsetup.oem file. Additionally, if no txtsetup.oem file exists, BMR creates one. In previous versions of BMR, the product attempted to process the txtsetup.oem file provided by an MSD manufacturer to identify installation drivers for the text phase. However, in some cases, there is no txtsetup.oem file to process or the txtsetup.oem file does not properly identify the driver. In other previous versions of BMR, the product attempted to process the driver information files instead of the txtsetup.oem file to identify installation drivers for the text phase. However, in some cases, an MSD uses a different driver for the text phase and for the graphical phase (when the inf files are used). The inf files do not specify the correct drivers in such cases.
Another issue encountered in identifying drivers for automated operating system installations occurs when gathering drivers from a running computer system (such as the computer system from which the backup is made). Some computer systems make use of virtual hardware devices. For example, virtual network interface cards (NICs) are often used for fault tolerance and/or load balancing purposes. When in use, a virtual NIC is mapped to a corresponding physical NIC (i.e. a NIC that is physically present in the computer system). Application software and even some operating system software uses the virtual NICs for network communications, and the virtual NICs may pass the communications to and from the physical NICs.
When virtual hardware devices are used, querying the running computer system to identified drivers is more complicated. The virtual hardware devices and physical hardware devices may both be indicated by the system (e.g. using various operating system application programming interfaces (APIs) and/or operating system files such as the Registry in Windows). However, the drivers for the devices may only be associated with the physical hardware devices. Drivers indicated for the virtual hardware devices, in some cases, cannot control the physical hardware devices. Accordingly, if a driver is selected from a virtual hardware device in the running computer system, the correct driver for the physical hardware device may not be identified. Additionally, in some cases, a virtual hardware device includes properties needed for installation and configuration. For example, transport control protocol/internet protocol (TCP/IP) properties may be including in the virtual NICs, in Windows systems.